Skip to main content

Architecture

Architecture is the set of decisions that are expensive to reverse. In digital health that usually means identifiers, terminology, the exchange model and the governance around them — not the choice of programming language or cloud provider, which teams tend to argue about far more.

This section covers how to describe a health system before building it, which frameworks help, and how to record the decisions so that the next team understands why the system looks the way it does.


The layers​

Every serious architecture description separates these concerns. The names vary between frameworks; the separation does not.

LayerQuestion it answersTypical artefacts
BusinessWhat health outcomes are we accountable for, and for whom?Service catalogue, stakeholder map, outcome measures
CapabilityWhat must the system be able to do, independent of software?Capability model, maturity assessment
ProcessHow does the work actually flow?BPMN workflows, Digital Adaptation Kits
InformationWhat do we mean by "patient", "encounter", "facility"?Conceptual model, glossary, registries
DataHow is that represented, stored, and moved?Logical and physical models, FHIR profiles
ApplicationWhich systems provide which capabilities?Application portfolio, platforms
IntegrationHow do systems talk?Interoperability layer, APIs, events
TechnologyWhat does it run on?Infrastructure, deployment topology
SecurityWho may do what, and how is that proven?Security architecture, threat model
GovernanceWho decides, and how do decisions change?Governance, architecture review board

The order that works​

The common failure is to start at the technology layer because it is the most tractable. A country buys an interoperability layer, then discovers it has no agreed patient identifier, no facility list anyone trusts and no legal basis for sharing data — so the layer routes messages nobody can act on.

A more reliable order:

1. Name the health problem "Women are lost to follow-up between ANC visits"
│
2. Identify the capability "Continuity of the maternal record across facilities"
│
3. Model the workflow Who does what, where, in what order
│
4. Decide the information model What is a "pregnancy episode"? Which identifier?
│
5. Choose standards FHIR profiles, terminology bindings
│
6. Design the exchange Which pattern — central, federated, hybrid?
│
7. Select or build applications EMR, CHW app, HMIS
│
8. Infrastructure and operations Hosting, availability, monitoring
│
9. Security, consent, governance Not a final step — a constraint on all of the above

Step 9 is written last only because it constrains everything above it. It is started first.


Reference architecture versus solution architecture​

These are different documents and confusing them wastes months.

Reference architectureSolution architecture
ScopeA class of systemsOne system, one context
Names technologies?Rarely — it names componentsYes, specifically
Owned byThe ecosystem (a ministry, a community)The implementing team
ChangesSlowly, by consensusPer release
ExampleOpenHIE, WHO Digital Health Platform"The ANC module deployed on OpenMRS 3 in Province 2"

A reference architecture that names vendors has stopped being one. A solution architecture that names none is not yet a plan.

Use the reference architecture template for the former.


In this section​


References​